home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
orad
/
orad-minutes-93mar.txt
< prev
next >
Wrap
Text File
|
1993-05-17
|
8KB
|
265 lines
CURRENT_MEETING_REPORT_
Reported by Bernhard Stockman/EBONE
Minutes for the Operational Area Directorate (ORAD)
Agenda
o Operations Area Mandates
- Operational standards
- Operational Requirements
- Operation Coordination
- Review of standards
o Coordination Issues
- Routing - Policy Language
- Routing Policy Registration
o Coordination of Tunnels
- MBONE
- TBONE
- *BONE
o Operational Impact if IPNG
o Class C Allocation Forecasts
Side notes
Do we need a single WG to handle issues regarding ``virtual Internets''
sitting on top of today's IP internet.
How will the large blocks of Class Addresses allocated affect current
routing platforms
Operational Area Mandates
Coordinations of network service providers; is it the job of the IETF?
``I can see no less biased venue.'' - Gene Hastings
Historically the IETF has been a venue for providers to discuss the
leading edge technology they have been deploying and to give developers
feedback.
1
It seems as if providers are swamped by the rapid growth of the
Internet. This forum allows providers to work on problems ``at the top
of the list.'' As the Internet continues to grow, more
``fire-fighting'' resources may become available. At that time some
other forum for NSP coordination may be appropriate... (i.e., Someone
else may be willing to host such a forum.)
Is it good to meet at the IETF? A great deal of technology of transfer
takes place. If a separate operational venue is developed, it should
collocate with the IETF. Another separate set of meetings would be
poorly attended, as network operators have too many meetings to attend
as it is.
As for reading for RFCs. If the Operational Directorate read RFCs,
would that alleviate some of the problems we have now? Many RFCs have
fallen through the cracks towards complete implementation without
operational issues being addressed (e.g., RFC1400). Informational RFCs
need to be addressed as they don't follow a standards track.
What about ``executive cooperation?'' A lot of informal agreements are
made at the IETF meetings, but they can't be backed without network
higher-ups agreeing to it. Thus the purpose of the meeting should be to
coordinate operation of individual networks, not to change each
network's own policy.
A certain amount of consensus is built up in the operational area. The
operational area seems to have fuzzy objectives and less concrete
standards.
NSP coordination actually also takes place within other organizations,
e.g., FARNET.
We'll continue to do things they way we are. If another forum develops,
it would be wise to collocate it with the IETF meetings.
One thing that ORAD needs to address is a mechanism to apply an ``ORAD
seal of approval.'' There needs to be a mechanism to alert ORAD to
[informational] RFCs which have significant operational impact.
John Curran agreed to make sure that the job of reading at least a
fraction of new RFCs for operational impact is handled. Bill Manning
agreed to do some reviewing, but cannot do the whole job himself.
There is a need for a working group to deal with a policy routing
description language. Many of the routing efforts (BRG, SDRIP, etc.,)
are defining a need for a common routing policy language. ORAD needs to
form a liaison with the protocol developers to help define such a
language.
It is possible that the Internet Working Group should be revived to deal
with topology configuration. Such a group could form the liaison with
the routing protocol developers to give input as to how develop future
protocols.
2
Dan Long's proposed structure (areas to be addressed):
o BGP Deployment - protocol/CIDR
o IWG - NSP Routing Coordination
o NSR - Growth
o Tunnel OPS - Coordinate the deployment of things like MBONE, etc.
o OPSTATS
o NOOP
o ORAD
o UCP (???) - Gas running out - Possible to roll into NJM
o Benchmarking - Bradner
o NJM (new) - coordination of NSP, trading troubleshooting
techniques, operational experience
Three different types of working groups:
1. Exchanging Information
2. Coordinated/establishing operational procedures
3. Engineering standards (e.g., benchmarking.)
4. IWG/Tunnel Ops - Operational planning.
5. NJM/UCP/NOOP - Diagnostic procedures
Tunnel Coordination
No critical mass to form an MBONE engineering group. However, a number
of different tunnel types may need to be organized to keep the
collection of ``BONES'' melts down the Internet.
MBONE seems to be causing operational problems. It is quite possible
that this is the first of many other tunnel types which will appear
again.
Matt Mathis reported the happenings at the MBONE BOF.
o General Issues
o Procedures
o Topology, Metric, and threshold engineering
o Bandwidth Budget and policy
o Infrastructure oriented tools (wish list)
o Transport and application diagnostic tools (wish list)
MBONE is only an example of very steep growth rates. It is hard to tell
end users to not to use their connection whether it be MBONE, AFS,
Internet Talk Radio, etc.
At this point there is no need to address these issues with a working
group, however it would probably be wise to hold some sort of meeting
3
before or at the next IETF. Discussion will be held on the ORAD list to
organize such a meeting.
Call C Allocation Forecasts
Will CIDR save us in time to keep our routers from falling apart from
too many routes? he number of Class C nets being allocated our quite
high. The NSFNET routing table has grown at a rate of 6.5% per month.
We'll probably see 10,000 routes by July. Is deploying CIDR going to
save us?
Which networks will hit the limit before CIDR is deployed? ANS feels
their situation is undercontrol, but other service providers may feel
the crunch.
Controlled deaggregation may need to be dealt with for those providers
who can't speak BGP4 but can't default. Ground rules need to be laid to
define this policy. A mechanism also needs to be defined for
negotiating the amount of aggregation which takes place between two
networks.
We're not sure when things will fall apart, so we may just have to deal
with the problem when it occurs. All we can do is keep trying to get
CIDR deployed in time and try to beat the clock.
ANS is also performing tests with cisco and IBM routers to see how many
routes can be flapped in and out before they suffer server performance
degradation.
Attendees
Tony Bates tony@ripe.net
Serpil Bayraktar sbb@noc.ans.net
Erik-Jan Bos erik-jan.bos@surfnet.nl
Rebecca Bostwick bostwick@es.net
Douglas Carson carson@utcc.utoronto.ca
Henry Clark henryc@oar.net
David Conrad davidc@iij.ad.jp
John Curran jcurran@nic.near.net
Tom Easterday tom@cic.net
Dale Finkelson dmf@westie.mid.net
Francois Fluckiger fluckiger@vxcern.cern.ch
Eugene Hastings hastings@psc.edu
Alisa Hata hata@cac.washington.edu
Ittai Hershman ittai@ans.net
Steven Hubert hubert@cac.washington.edu
Dale Johnson dsj@merit.edu
Merike Kaeo merike@alw.nih.gov
Daniel Karrenberg daniel@ripe.net
Charley Kline cvk@uiuc.edu
Daniel Long long@nic.near.net
Kim Long klong@sura.net
4
Peter Lothberg roll@stupi.se
Glenn Mackintosh glenn@canet.ca
Bill Manning bmanning@sesqui.net
Matt Mathis mathis@a.psc.edu
Dennis Morris morrisd@imo-uvax.disa.mil
Peder Norgaard pcn@tbit.dk
David O'Leary doleary@cisco.com
Andrew Partan asp@uunet.uu.net
Brad Passwaters bjp@sura.net
Kim Smith kas@noc.ans.net
Bernhard Stockman boss@ebone.net
Marten Terpstra marten@ripe.net
Kaj Tesink kaj@cc.bellcore.com
Claudio Topolcic topolcic@cnri.reston.va.us
Curtis Villamizar curtis@ans.net
Ruediger Volk rv@informatik.uni-dortmund.de
Linda Winkler lwinkler@anl.gov
Cathy Wittbrodt cjw@barrnet.net
Paul Zawada Zawada@ncsa.uiuc.edu
5